feat: Nvim can detect venv python via "pynvim-python" tool #594
Conversation
drmikehenry
force-pushed
the
pynvim-python
branch
from
b84ce2d to
d72acec
Compare
|
Are any of the CI failures related? |
Problem: Detection of the pynvim module is currently done by finding the
first Python interpreter in the `PATH` and checking if it can import
pynvim. This has several effects:
- Activation of an unrelated Python virtual environment will break
automatic detection, unless pynvim is also installed in that
environment.
- Installing pynvim to the expected location is difficult. User
installation into the system-wide or user-wide Python site area is now
deprecated. On Ubuntu 24.04 with Python 3.12, for example, the
command `pip install --user pynvim` now fails with the error message
`error: externally-managed-environment`.
- Users may create a dedicated virtual environment in which to install
pynvim, but Neovim won't detect it; instead, they must either activate
it before launching Neovim (which interferes with the user of other
virtual environments) or else hard-code the variable
`g:python3_host_prog` in their `init.vim` to the path of the correct
Python interpreter. Neither option is desirable.
Solution: Expose pynvim's Python interpreter on the `PATH` under the
name `pynvim-python`. In the typical flow:
- User installs either uv or pipx.
- User installs pynvim via:
uv tool install --upgrade pynvim
# Or:
pipx install --upgrade pynvim
With corresponding changes in Neovim, the above is all that's needed for
Neovim to detect the installed location of pynvim, even if an unrelated
Python virtual environments is activated. It uses standard Python
tooling to automate the necessary creation of a Python virtual
environment for pyenv and the publication of `pynvim-python` to a
directory on `PATH`.
See neovim#593 for additional
discussion of this idea.
drmikehenry
force-pushed
the
pynvim-python
branch
from
d72acec to
466ffc8
Compare
|
I've added docstrings to Tests and QA are passing on my local machine (invoked as Testing against the The failing test is in def test_options(vim: Nvim) -> None:
vim.current.window.options['colorcolumn'] = '4,3'
assert vim.current.window.options['colorcolumn'] == '4,3'
# global-local option
vim.current.window.options['statusline'] = 'window-status'
assert vim.current.window.options['statusline'] == 'window-status'
assert vim.options['statusline'] == ''
with pytest.raises(KeyError) as excinfo:
vim.current.window.options['doesnotexist']
assert excinfo.value.args == ("Invalid option name: 'doesnotexist'",)This chooses I used The diff --git a/test/test_window.py b/test/test_window.py
index 7a36d9e..9267a14 100644
--- a/test/test_window.py
+++ b/test/test_window.py
@@ -61,10 +61,11 @@ def test_vars(vim: Nvim) -> None:
def test_options(vim: Nvim) -> None:
vim.current.window.options['colorcolumn'] = '4,3'
assert vim.current.window.options['colorcolumn'] == '4,3'
+ old_global_statusline = vim.options['statusline']
# global-local option
vim.current.window.options['statusline'] = 'window-status'
assert vim.current.window.options['statusline'] == 'window-status'
- assert vim.options['statusline'] == ''
+ assert vim.options['statusline'] == old_global_statusline
with pytest.raises(KeyError) as excinfo:
vim.current.window.options['doesnotexist'] |
Please add that as a separate commit here, so we can get a better idea of CI status. |
The test previously depended on the 'statusline' option being empty by
default. The default 'statusline' value changed in Nvim commit
28e31f5d3d16fac349d5e2b55837afddb822b0f3 (2025-04-22):
feat(options): default statusline expression #33036
Adjust the test to first read the default (global) value of
'statusline', then change the local value of the option, then re-read
the global value and verify it hasn't changed.
|
I've added a commit to fix |
|
The failing |
justinmk
changed the title
Problem: Detection of the pynvim module is currently done by finding the first Python interpreter in the
PATHand checking if it can import pynvim. This has several effects:Activation of an unrelated Python virtual environment will break automatic detection, unless pynvim is also installed in that environment.
Installing pynvim to the expected location is difficult. User installation into the system-wide or user-wide Python site area is now deprecated. On Ubuntu 24.04 with Python 3.12, for example, the command
pip install --user pynvimnow fails with the error messageerror: externally-managed-environment.Users may create a dedicated virtual environment in which to install pynvim, but Neovim won't detect it; instead, they must either activate it before launching Neovim (which interferes with the user of other virtual environments) or else hard-code the variable
g:python3_host_progin theirinit.vimto the path of the correct Python interpreter. Neither option is desirable.Solution: Expose pynvim's Python interpreter on the
PATHunder the namepynvim-python. In the typical flow:User installs either uv or pipx.
User installs pynvim via:
With corresponding changes in Neovim (neovim/neovim#35273), the above is all that's needed for Neovim to detect the installed location of pynvim, even if an unrelated Python virtual environments is activated. It uses standard Python tooling to automate the necessary creation of a Python virtual environment for pyenv and the publication of
pynvim-pythonto a directory onPATH.I've aimed to update all relevant portions of the documentation. I'm happy to make adjustments, or you may feel free to make changes as needed.
Close #593